An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hello, Our app (Apple ID 6797897487) is an internal operations tool built under contract for a single business. It was rejected under guideline 4.3(a) on 29 August. We replied in App Store Connect on 31 August and on 10 September, adding that Apple had approved unlisted app distribution for the app on 8 September, but we have not received any response since. What is the recommended next step here? Should we resubmit the same build with the updated information, or wait for a reply to the existing messages? Thank you.

Our app, Roll (Apple ID: 6797953438), has received two Guideline 4.3(a) spam rejections. Our responses have gone unanswered for almost 3 weeks, and then we got an account warning. August 27: First rejection. We replied requesting clarification, explaining the app’s functionality, and supplied a walkthrough video. September 14: After almost three weeks without clarification, we submitted a substantially revised build with new functionality. We included an explanation directly in the App Review notes. September 15: The exact same rejection, still without identifying the issue or addressing our notes to them. This time, it included a warning about account removal for repeated noncompliance. It seems Apple is refusing to read our replies. Instead, they got back to us with the same rejection and a warning. For what? Doing as we were told and writing a reply? Note that thus far, NONE of our replies have even been acknowledged. Has anyone resolved a similar 4.3(a) rejection? What helped you get specific clarification or a call with App Review?

Hello App Review, Our iOS app was rejected under Guideline 5.6 (Developer Code of Conduct). The message states that the app appears to contain features intentionally hidden during review, and that this pattern is commonly associated with fraudulent activity. We want to address this correctly, but the current note does not identify the specific flow, screen, or behavior that was observed. Without that, we cannot investigate the exact issue. Could a member of App Review please follow up in App Store Connect with more concrete detail, or advise what we should check? @WWDR App name: Prime Cedi Loan Apple ID: 6808185084 Version: 1.1.0, Build 2 Guideline: 5.6 We have already replied in Resolution Center and are ready to provide test accounts, a demo video, or a phone call if that would help. Thank you.

Hi, our prediction market app, Even, has been rejected under Guideline 5.3.4. Even is a mobile frontend built on Polymarket’s markets and trading infrastructure. Apple says we have not provided licensing and permission documentation for every country or region selected in App Store Connect. It has also asked us to limit App Store availability and app access to licensed locations. We’ve added geoblocking so users in restricted regions cannot place orders; they can only browse public market information in read-only mode. We also updated our App Store description to explain our relationship with Polymarket and the regional restrictions. We’ve noticed other prediction market apps that appear to be available across many App Store regions with trading enabled. We may not know what licenses or arrangements those developers have, but we’d appreciate help understanding why our submission is being treated differently and what evidence Apple needs from us. For a third-party frontend, does Apple require our own licensing documentation for each region, or could authorization and documentation from the underlying market operator satisfy review? Is read-only access in restricted regions insufficient under Guideline 5.3.4?

Hey Apple Developers! I am about to release my first iOS Application, but I am having a hard time with the app reviews. Here some curiosities I just don't understand. Hopefully you can tell me why the app was rejected and what I have to do in order to make it work... Review A: Apple first responded with: Guideline 2.5.4 - Performance - Software Requirements Due to the usage of Bluetooth Low Energy and the Core Bluetooth framework and Guideline 2.1 - Information Needed The App Tracking Transparency permission request, due to the usage of Ad frameworks. So I created a video in which I explained why I need it and anotherone where the ATT dialog appears. (since I am from germany, I even used a VPN to "simulate" the appearance of the ATT Dialog in the US, since in the EU dialog this looks a bit different. The EU version of it was visible in the initial video I provided. After that (still same request ID) it got rejected because the IAP was missing in the review request, even though it was in there. BLE and ATT wasn't a problem anymore I thought, well may be they've overseen the IAP, so I created a complete new request, uploaded a new (further developed) application. No changes on the IAP, ATT nor BLE parts. Review B: Again this was declined, for the same reasons review A was declined the first time. I explained EXACTLY the same thing, as in review A. The only answer was: We appreciate your efforts to comply with the App Review Guidelines. Please resubmit the app for review in App Store Connect once any necessary adjustments have been made. We look forward to reviewing your resubmitted app. I thought: Well, may be it's not possible to approve an app that was once declined (as mentioned this is my first review) So I created a new review request. Review C: Including a new video for the app itself (I was had developed some progress already) and the BLE video again (to prove the usage of CBPeripheralManager and CBCentralManager) It got decline AGAIN. Reasons: Guideline 2.5.4 - Performance - Software Requirements BLE again Guideline 5.1.2(i) - Legal - Privacy - Data Use and Sharing ATT Problem again. Again, explained where to find it and even provided timestamps for the videos on where to find the ATT. (There were 2 reviews upfront this story without the Ad/ATT part already, that's why I wrote "...5th request") I am very frustrated right now and I have no clue what I am supposed to do here. It might be that I am doing something wrong here (as mentioned, first apple review), but please, let me know what that is!

Hi, our new app Amisoria (App ID 6805385809, Submission ID 95e40745-299b-4467-b9f6-8dd5ca907b02) was submitted Aug 29. On Aug 30 we received a Guideline 2.1 "Information Needed" message; we replied Aug 31 with all eight requested items including a screen recording, and followed up on Sep 3. We also opened Developer Support case 102955409950 on Sep 7. There has been no response of any kind since Aug 30. Could someone from App Review please take a look? The app is a client for a self-hosted AI gateway; a built-in demo mode lets reviewers test it without any server. Thank you.

To the Apple Review and Developer Support Teams, I am writing to request guidance and assistance regarding a persistent rejection my React Native application is facing under Guideline 2.1 - Performance (In-App Purchases). My app has been rejected multiple times with the following specific note: "The In-App Purchase products in the app still exhibited one or more bugs which create a poor user experience. Specifically, the subscription screen failed to load any subscription plans. Review the details and resources below to troubleshoot this issue." The screenshot provided by the review team shows a completely black screen where our paywall options are intended to populate, indicating that the product array is returning completely empty during the review process. The Dilemma: We are completely unable to reproduce this behavior on our end. Everything functions flawlessly within our TestFlight builds across multiple physical test devices and various sandbox tester accounts. On TestFlight, the paywall renders instantly, local pricing fetches immediately via SKProductsRequest, and test transactions process without a single error. Our Current Implementation & Verification: Product Status: All subscription products are explicitly marked as "Waiting for Review" in App Store Connect with one In-App product Rejected for not being attached with a bin but I've since submitted the app once again. All the subscriptions and the in-app product have been actively attached to this specific app submission version. Agreements: The Paid Apps Agreement is active, signed, and fully up to date within our Agreements, Tax, and Banking configurations. Identifiers: We have strictly verified that the hardcoded product identifiers in our React Native codebase match the App Store Connect product IDs exactly. Because this error only occurs within the App Review environment and never in TestFlight or local sandboxes, we are at a loss for how to debug or resolve this issue. Could the App Review team or the Developer Support technical team please clarify if there is a known environment mismatch, storefront routing discrepancy, or specific network configuration (such as IPv6 handling in the review sandbox) that would cause production-ready StoreKit products to return an empty array exclusively to the reviewer? Any direct guidance, logs, or steps on how we can successfully surface our plans to your review team would be deeply appreciated. Review Environment Submission ID: 5a35279c-1621-4972-b6c6-7c1fb202b2f0 Review date: May 20, 2026 Review Device: iPad Air 11-inch (M3) Version reviewed: 1.0.2 (8) Thank you for your time and assistance.

Hello, I’m looking for some advice regarding a TestFlight Beta App Review issue. My app, MyStory, was rejected twice under Guideline 2.1(a) with the same general message: App Review was unable to successfully access all or part of the app. In the first review, Apple specifically asked us to provide a demo account with content demonstrating the app’s functionality. We followed those instructions for Build 3: • Created a dedicated demo account with sample content in all four sections. • Added the username and password under Beta App Review Information. • Added testing instructions. • Replied to App Review with the credentials and instructions. Build 3 was nevertheless rejected again under the same Guideline 2.1(a), without specifying which part of the app was inaccessible. We have tested the app and the demo account ourselves, and everything works as expected on our devices. The app can also be used without an account, and users can create an account directly within the app. We have now replied to App Review asking them to identify the specific screen, step, or functionality they were unable to access. We are currently waiting for a response. Has anyone experienced a similar situation? In particular, I would appreciate advice on how to get a more specific explanation from App Review, or whether there is an appropriate way to escalate the issue if they cannot identify what was inaccessible. I’m also wondering how reliable the 24-hour response timeframe is in practice. It has now been more than a day and a half since I replied to App Review. Should I expect a response within a few days, or can Resolution Center replies sometimes take considerably longer? Thank you.

Hello, I have been experiencing repeated “spam” rejections across several app submissions, including apps that are unrelated to one another, and I would appreciate advice from developers who have encountered a similar situation. I initially developed a sports-themed deckbuilding game and created separate versions based on different sports. Although they share a general concept, each version has its own sport-specific rules, terminology, progression, and gameplay systems. For example, the basketball version uses drafts, while the football/soccer version uses transfers. Three of these sports versions were approved, while three others were rejected as spam. I understand that apps based on a shared concept may require additional clarification, so I explained the differences between them during the review and appeal processes. However, subsequent apps that are completely unrelated to those sports games have also been rejected as spam. This includes: A paid game with a different concept and gameplay A free meeting app with no purchases, subscriptions, or paid content The meeting app was also initially questioned because the review team could not locate a payment mechanism. However, there is no payment mechanism because the app is entirely free. All features are available to every user, and creating an account is optional. My Apple Developer account has been active since 2019, and I had not experienced this pattern before. Because unrelated submissions are now receiving similar rejections, I am concerned that the reviews may be influenced by an account-level classification rather than an individual assessment of each app. I submitted appeals and provided detailed explanations, but I have been waiting for approximately two weeks. The response I received stated: “Due to increased volume, we’re working toward investigating your appeal.” The overall issue has now been ongoing for nearly two months. Has anyone experienced repeated spam rejections affecting otherwise unrelated apps? If so: Were you able to request a broader review of your developer account? Is there a recommended escalation channel beyond the standard appeal process? What supporting information helped demonstrate that the apps were sufficiently different? Is it normal for appeal investigations to take several weeks? I am happy to provide the review team with comparison documents, gameplay videos, detailed feature lists, or any other information needed. I would mainly like to understand the most appropriate way to have each app evaluated based on its own functionality and content. Thank you.

Hi everyone, We submitted a critical update for our iOS app, Hook - AI Rizz Wingman (Apple ID: 6766006483, Bundle ID: com.hook.eden), which contains an essential bug fix for our post-onboarding paywall and subscription flow integration. The build has been stuck in the "Waiting for Review" status for over a week now. Due to the severe impact of the paywall bug on our active users, we also submitted an Expedited Review request, but the status remains completely unchanged and stuck in the pipeline queue without moving to "In Review". Is anyone else experiencing major system delays with the review queue this week? Are there any recommended steps to have a moderator check if this specific build or Apple ID is flagged or stuck in a broken pipeline state, without triggering a re-submission that would lose our place in line? App Details: App Name: Hook - AI Rizz Wingman | Apple ID: 6766006483 | Bundle ID: com.hook.eden | Issue: Paywall & Purchase Flow Critical Hotfix Stuck in Queue. Any insights or moderation checks would be greatly appreciated!

We recently received a 14-day compliance notice regarding Guideline 3.1.2(c) for one of our live apps. We promptly submitted an updated build addressing the subscription flow. However, the build received a Guideline 2.1 (Information Needed) rejection, requesting navigation paths and sandbox reproduction steps for specific In-App Purchase product IDs. Following their instructions to simply reply with the requested information without uploading a new binary, we provided a comprehensive step-by-step PDF navigation guide and submitted our response via App Store Connect yesterday. Because no new binary was uploaded, the submission status remains "Rejected", and our 14-day compliance grace period is expiring in less than 48 hours. We are quite concerned about potential disruption to the live app's availability while waiting for the team to pick up and review our response. Has anyone experienced a similar situation right near the 14-day deadline? Does having an active reply pending review under a "Rejected" status prevent automated removal from sale? Is there any recommended way to flag this urgency to the App Review team beyond the expedited review request (which we already submitted)?

Hello, Our app has been in "Waiting for Review" since September 8 with no status change. It has never moved to "In Review." Steps already taken: Expedited Review Request, approved on September 11, but status did not change Contacted App Review Support for a status update, no response Requested a call, no call has taken place We have received no rejection, no request for additional information, and no messages in Resolution Center. This is time-sensitive: we have a real-world community event on September 19 in Düsseldorf, Germany, tied to this launch. App: KIBAKI: Persian Community Apple ID: 6797615150 Version: 1.0.36 (35) Submission ID: d1f921a3-9001-4ef2-a392-657860c437cd Submitted: September 8, 2026 Could the App Review team please check whether this submission is stuck in the queue? Thank you.

Asking as an individual developer, before building further. Relevant guidelines: 2.5.14, 5.1.1, 5.1.2. Remote support apps are established on the App Store: the user starts a broadcast with RPSystemBroadcastPickerView and a Broadcast Upload Extension, and a human agent views their screen to help them. My design is identical except the frames go to an automated analysis service instead of a human. The results return only to the same user who started the session, to help with their own task on their own device. The design: sessions are started and ended by the user through the system picker, with the standard broadcast indicator visible throughout. Frames are transmitted transiently, never stored, and never seen by any person. There is no remote control or synthetic input of any kind. Captured data is used only for the in session assistance, with explicit consent and privacy policy disclosure per 5.1.2(i). Is swapping the human viewer for an automated analyzer acceptable under the guidelines? And does automated processing of screen content require any disclosures or consent beyond what human viewing requires? Thanks for any guidance.

Xcode version 26.6 (17F113) MyOwnKeyboard-PAD app looks OK using simulator iPad Air 11-inch(M4). It automatically reformats to all orientations using only left and right landscape selected in General, Deployment Info. The submitted app 1.9 (4) had the portrait checked which was an error. I tried to update to version to 1.10 without portrait and upside down, but Validation states it must have all orientations needed. I tried setting all orientations and the simulator cuts off the sides. I am using a new mini M4 with Tahoe 26.6.2 Converted from an older developer mini using Migration Assistant. After conversion Xcode could not find xcspace files and apps locked up. I had to create new apps with different bundles which got conflicted in AppConnects causing rejects. When new versions are submitted, old versions cannot be removed because of submission states. Causing similar binaries, design and scam. I got trapped in the process! I have replied to AppConnect ref. binaries, design and scam. I hope someone can straighten this mess out. The good new is the free MyOwnKeyboard-PHONE analytics look OK with 4,000 impressions and 38 downloads and 172 product page reviews. It's a start! Thank you. Charlie Coupe Designer/Coder 2026sep16

Has anyone successfully appealed an Apple Developer account termination under Section 3.2(f)? My individual developer account (about 50 live apps, all my own work, all revenue through StoreKit subscriptions) was terminated effective August 24, 2026 under Section 3.2(f) of the ADP Agreement. I believe it was triggered by internal tooling I built to automate my own App Store Connect workflow — metadata, build uploads, submissions — only on my own apps. I've filed an appeal through the official form, replied to the termination notice, and written to appstorenotices. For anyone who has been through this: Did your appeal succeed, and how long did Apple take to respond? Was the response you received a form letter or specific? Were you able to recover the withheld balance from legitimate sales, and through what channel? Is there any official channel I've missed beyond the appeal form, the termination-notice reply, and appstorenotices? Any firsthand experience would mean a lot. Thank you.

Dear App Review Team, Our app No.IA (Apple ID: 6768742372) has been in "Waiting for Review" since July 20, 2026. This is version 3.1, resubmitted after the App Review Board cleared Guidelines 2.3.1 and 3.2.1 (Appeal Ticket APL509468). All Guideline 1.1 concerns have been addressed: metadata rewritten, in-app labels updated, screenshots replaced. We have tried: Resolution Center reply, expedited review request, phone call to Developer Support (Case 102912803305). All responses have been generic with no timeline. This app has been in review processes since May 19, 2026 — over 75 days. Any assistance would be greatly appreciated.

Dear App Review Team, I am writing to respectfully request an update on the review status of our first-time app submission, which appears to be stalled in the queue. Here are the specific details of the submission: App Name and Version: Bingo Rewards! (Version 15.54.34) App ID: 6793050466 Bundle ID: com.apperfun.bingorewards Submission Date: August 31st Current Status: The build remains strictly on "Waiting for Review" and has not transitioned to "In Review." Previous Actions: This is our first app submission. The initial build was previously rejected, after which we thoroughly fixed and addressed all noted issues before resubmitting this current version on August 31st. Given that the app has been in the "Waiting for Review" status for over a week following our resubmission, we wanted to ensure there are no outstanding requirements or technical blockers on our end preventing the review from moving forward. Please let us know if you need any additional information or clarifications to assist with the evaluation of this build. Thank you for your time and assistance.

I am trying to add testers to External Tester groups for a couple of our iOS apps and after adding them it shows "No Builds Available". This is despite the app being available to that External Tester group with other people having already installed the latest version of the app which is "Available" and not expired. Can someone please fix this? It is so frustrating the number of times I try and release apps to TestFlight and there's some issue blocking me, completely out of my control and I have to rely on someone at Apple fixing something on this terrible AppStoreConnect system.